Service Portfolio Management

Service Portfolio Management is the process responsible for managing the complete set of Services that are managed by a Service Provider.

You can operate a service-centric approach to Service Management using Ivanti Service Desk. This is a key concept behind ITSM and ITIL 2011, and takes a typical ITSM service desk beyond the basics of Incident, Problem and Change management into the more advanced activities of Capacity Management, Availability Management and Financial Management.

Service lifecycle

To start managing a portfolio of processes, firstly create your new Service Lifecycle process. This would typically step through all the activities in moving a Service through ITIL activities defined in Strategy, Design, Transition, Operation (with Improvement) and eventual decommissioning and end of life. In ITIL, Services in the Portfolio pass through these activities and become Defined, Analyzed, Approved, and Chartered, indicating the movement through the Lifecycle process. The activities in these ITIL phases enable you to plan and specify the future KPIs and usage of the Service. Your Portfolio of Services becomes the full set of lifecycle-driven Services that are at various stages in their Service lifecycles. To create a new portfolio record, raise a new instance of the Service Lifecycle process. This then guides your business through the required steps – for example creating a value proposition, a service design package (SDP), capacity plan, availability plan, and defining future availability and capacity limits. Typically this includes linking the Lifecycle process to the Service CI so that the Status of the Lifecycle process can be seen from the CI. The first step of this process is to add an existing CI to the process, or to create a new CI. After this, you can add requirements, authorize, design, build, test, and then release the Service.

When the Service is released, the process moves to a Live status. At this status, you can add Create Child Change actions that create an instance of this Service, which can then be managed separately.

From the Live status, you also add a Retire action, to move the Service lifecycle to a Retired end status.

You can then add a filter query tab to the Service window to display the status of the Service Lifecycle process for the Service you are viewing.

Changing the default queries used in the Service Catalog to display only those Services that have a Lifecycle status of Live enables you to control the availability of Services through the Service Catalog to only Live services.

The ability to use the lifecycle process to enforce anticipated expected usage, capacity, availability, and cost values is the key to Service Centric ITSM. The Service Lifecycle guides IT into planning the expected values for operation, against which the actual values can be compared.
This leads to monitoring of service usage and performance against targets, and then onto service improvement as limits are exceeded.
Assessment of future changes, growth and risk all take place based on the current values, and target and maximum values on the Services in Service Desk. Often, proactive service improvement activities include reference to identifying risks, and implementing the changes to negate those risks before they bring current values beyond service value thresholds.
Other fields typically included on a Service include Cost (to IT) and Charge (to business). These directly support Financial Management activities and enable charge-back and financial service accounting.

Design Idea: Your Service CI can be created manually when prompted from the process, or can be created automatically populated from values recorded in activities on the Lifecycle process.

The status of the Lifecycle process defines the status of the Service. You can see this status from the Service by adding a filter query to the tabs on the Service CI window showing the Service Lifecycle status. You can also add any other attributes that you require on the CI (name, purpose, description, cost code, business impact, and so on) to the Service window.

To view your Service Portfolio: query a list of Services lifecycles with status, name, description and any other fields required.

To view your service pipeline: query a list of Services as above whose statuses are all in pre-Operation phases.

To view your Service Catalog: query a list of Services as above with a status of Live (or other suitable status in the Operation phase).

To view your retired services: query a list of Services as above with a status post-live (decommissioning or retired).

To view your services in use: query over the User Config Item table to view services by customer or customers by service.

Remember that your Service, once in live operation, is ideally under change control. Any developments and evolution to that Service are managed as standard Change processes, linked to the Service CI. Also once in operation you can update the Service window (or a collection) with values obtained from external systems using a scheduled Import. This provides you with a location to store snapshots of the latest monitored availability/capacity information to compare against those figures identified in the planning stages. Typical metrics you can derive and compare against planned limits includes Service Usage (the number of users subscribed or linked to the service).

You can deliver Services from a number of routes. Once you have the structure enabled as described, you can include Services delivered to you from third parties, which may or may not be component Services in larger IT Services. The same concepts apply. The supplier of the Service, internal or third party, is described in the Service Provider field on the Service window.

Continual Service Improvement

Design idea: Continual Service Improvement can be a looping activity of performance review on a live service. You can enable on-going service improvement plan (SIP) activities by setting a Due Date for review and a status for In Review or Out of Review.

As you refine the definition of your Service, the Service CI window becomes an increasingly critical point to hold all information relating to the Service. When you publish Services through the Service Catalog, the Service Description is usually presented to the end-users, so remember to word the descriptions in user-friendly text. If you need a formal document describing the service, you can either attach a separately prepared document to the Service, or you can generate the document automatically from the values held on the Service. For example, you can run a Crystal Report that formats into a document layout, or you can automatically generate Word documents attached to the process at the required point in the process.

For more information about Word Integration, see Word Integration.

Self Service and Service Catalog

When a service in the portfolio reaches a status of To release, it appears in the Service Catalog Administration component to be published.

You can change the appearance of Self Service and the Service Catalog. The Service Catalog layout is defined in Service Desk using a Reports Template on the Configuration Item object in Object Designer. By editing this, you can change the appearance and layout of your catalog. For example, you can add other fields such as: Cost, Approval, Supporting Documents, and so on. Although you can include usage documentation at this point, you may prefer to provide this as a part of the fulfillment process. Refer to the Ivanti Community for examples of different Self Service and Catalog designs.

Managing Multiple Services

There are several ways to manage multiple linked Services. Remember that Services are CIs, so you can link them in CI structures to all component CIs and Services. This provides a graphical Service relationship view as described elsewhere in this document. However, in offering the ability to request new Services through the Catalog you can also link delivery of items in more than one way:

• On the Fulfillment process raised from the Catalog, you can include the steps to ensure that each component delivery is made. For example, assign the Request to Education to provide Training, or generate a new child Request for Training.
• The Bundle function in the Catalog enables multiple linked Services to be bundled together, so that one Request initiates a bundle of individual Requests.
• Using the Shopping Cart, you can request multiple items. The Cart will not prompt if a required sub-item is not included, so this option provides more choice, but less enforcement.

Defining Service Levels

Set the definition and agreement of the levels of service available with your new Service during the Design stages of your Portfolio process. Usually, standards such as Gold, Silver, and Bronze are defined at early stages, and then linked to the individual customers as and when the customer-service agreement takes place.

Define your Service Level standards on the CI Service window (using text fields labeled Gold, Silver, Bronze, and so on). You can also attach complete SLA documents using the Attachment action or button. You can then link to the relevant SLAs for the Service, either by clicking the Service CI on the Lifecycle definition, or clicking the attached documents collection.

As mentioned above, you can link from your Service definition to Availability, Capacity and Financial management activities. The target values identified on the Service for availability and capacity are set in the design stages, and the latest values are updated automatically from external monitoring tools into collections on the Service definition. Click the Capacity data and Availability data tabs to see Availability and Capacity 'latest' values. These values are also used to produce Capacity and Availability planning and performance reports. For financial management, click into the target values for Service Cost and Service Price.